ターゲットトラッキングポリシーを利用した、EC2のオートスケール設定を実施してみた
はじめに
AWSチームのすずきです。
2017年7月のアップデートにより、「ターゲットトラッキングポリシー」を利用したEC2のオートスケール設定が可能になりました。
新機能 – EC2 Auto Scalingのターゲットトラッキングポリシー
今回、ALB(Application Load Balancer)のターゲット別リクエスト数が指定した値を超過した場合のスケールアウト設定を、「ターゲットトラッキングポリシー」利用して設定する機会がありましたので、紹介させて頂きます。
構成図
- 一般的なWeb3層システム、ELBはALBを採用するシステムです。
設定
Auto Scaling グループ設定
スケーリングポリシーの作成
- ターゲットトラッキングポリシーとして、「ターゲット別の Application Load Balancer リクエストの数」を指定した設定を実施しました。
- オートスケールの発動によりEC2インスタンスの起動、撤去が繰り返される事を回避するため、スケールインは無効としました。
- ターゲットトラッキングポリシーの対象としては、EC2のCPU使用率、EC2のネットワーク転送量を利用する事も可能です。
スケジュールされたアクションの設定
- スケジュールされたアクションとして、平時予想される負荷に応じたEC2台数を希望数、最小数として設定しました。
- 予想以上のリクエストが発生した場合、ALBのリクエスト数をターゲットトラッキングポリシーとしたスケールアウトを発動させる想定で、最大数を設定しました。
- リクエストが収束する夜間、希望数、最小数を減らすスケールイン設定をしました。
確認
Cloudwatch アラーム
- 作成したスケーリングポリシーは、Cloudwatchのアラームとして確認が可能です。
- 指定したしきい値を超過するとアラームの状態がOKからALARMとなり、オートスケールが発動した事を確認できました。
Cloudwatch ダッシュボード
-ApplicationELB、Auto Scaling、EC2のAuto Scaling グループ別のメトリックを一覧で比較するため、Cloudwatch ダッシュボードに登録しました。
ALB情報
- HTTP応答コード別のリクエスト数、ターゲット別のリクエスト数、ターゲットの応答時間を確認しました。
- ターゲットの応答時間、90〜99%タイルの値が悪化しない事を目標に、オートスケール設定を調整します。
- 今回のスケールアウトの発動はやや早すぎた可能性が高く、しきい値を高め、EC2の起動台数を抑える方向で調整しました。
Auto Scaling、EC2
- オートスケールの発動によりインスタンスが増加し、EC2、1台あたりのCPU負荷(CPU Utilzation)が減少した事を確認できました。
- インスタンスファミリー「t2」を利用する場合、CPUクレジットの枯渇はシステム性能に大きな影響を及ぼします。オートスケールのしきい値調整の際、CPUCreditBalanceの値を指標として、合わせて確認する事をおすすめします。
まとめ
「ターゲットトラッキングポリシー」を利用する事で、オートスケールをより簡単、直感的に設定する事ができる様になりました。
リクエスト数に比例してEC2(Web/APサーバ)の負荷が上昇するシステムでは、 ALBのターゲット別リクエスト数をトラッキングポリシーとした設定は有効と考えられます。予期せぬ負荷が発生した場合の保険として是非ご活用ください。
